Many types of application programs are currently available for personal computer systems, such as word processing programs, spread sheet programs, personal calendar programs, multimedia programs, etc. These application programs typically include a number of components that function, in many respects, as independent entities. Each component is typically configured as a separate module or object in an object-oriented operating environment.
Although a component is an independent module, it defines an interface--a standardized communication syntax--for communicating with it. In this manner, virtually all of the functionality of the application program may be implemented through a set of cooperating components. For example, a word processing program may include a separate component for each document that the user has opened, as well as separate components for the tool bar, each item in the tool bar, each pull-down window that can be activated from the tool bar, each individualized user interface that can be activated from the tool bar, etc.
Each component usually, but not necessarily, includes a graphical user interface aspect, which is typically referred to as a window. When a user selects a particular component, the component may become instantiated, which means that the component's window is created and displayed. The user may then interact with the component by sending input messages to the component. For example, a user may open a word processing document and then use the keyboard to enter text into the document. Many components may be simultaneously instantiated, and the set of instantiated components changes dynamically as the user operates the computer system, opening windows, closing windows, selecting functions, and so forth.
Because more than one component may be instantiated at the same time, each component has the capability of becoming active, which is also referred to as receiving the focus. When a component has the focus, it receives general input messages from the user input devices, such as the keyboard and the mouse. The user changes the active component by using a predefined activation command. For example, some components may be activated by navigating the pointer near or over a top level or displayed portion of the desired component, other components may be activated by through a point-and-click command with the pointer on a top level portion of the desired component, and these or other components may be activated through predefined keyboard commands.
The object-oriented operating environment allows components developed by different groups to be integrated into a cooperating whole. This allows program modifications and improvements to be implemented by adding new components that define new functionality to a preexisting application program. The program developers therefore provide tools, such as interfaces, to help integrate newly created components into a preexisting set of cooperating component. It is important, of course, that the various components cooperate properly with each other.
With this in mind, the program developers typically build as much functionality into an application programs as possible, given a particular release date. But desirable new features and options are almost always identified after the release date. And in many case, certain features may only be desirable for a select group of users, whereas other users may prefer a different set of features. For this reason, tools that often referred to as a "software developer's tool-kit" or "SDK" are often provided to allow developers to make post-release modifications to an application program. Much effort goes developing SDKs and making application programs amenable to post-release modifications. In fact, the developers of an original application program may intend that software developers will use an SDK to create new components for the application program that were never anticipated by the original program developers.
Generally stated, there is a need to integrate components, including post-release components developed using an SDK, with the other components of an application program so that all of the components operate properly in conjunction with each other. There are a number of objectives when integrating the component that are not satisfied by prior component integration systems. In particular, there are a number of objectives that are not met for integrating post-release components into a preexisting application programs.
In prior art component integration systems, the operating system coordinates the routing of the focus and input messages to application programs that are running on different threads or processes. Because each thread or process may operate its own message loop, the coordination provided by the operating system allows each of the application programs to receive message loop services. However, the operating system gives no support to providing message loop services to multiple components running within a single thread or process. It would be advantageous, therefore, for the components running within a single thread or process to be able to receive message loop services.
For example, a component may be capable of changing a global state parameter of the application program, such as turning on or off a warning message feature or a background printing feature. It would be advantageous for the application program to take notice of this type of global program state changes so that the state will remain set when the user activates another component. For instance, if the user turns a warning message feature off when a post-release component is active, it would be annoying if the warning message feature remained on when other components are subsequently activated.
Notification of a modal state invoked by a component is another one of the critical pieces that is missing in prior component integration systems. When a component enters a modal state, such as a spin dial or another multi-item selection device, it typically displays a special user interface that requires a response from the user before terminating the modal state. Therefore, it would be advantageous for the windows for the other instantiated components to be disabled so that they cannot be activated until the modal state has been terminated. Prior component integration systems are restricted in their ability to disable peer-level components, which interferes with and limits the flexibility of modal state functions.
More importantly, a component must not operate in a way that conflicts with the operation of the underlying application program. A typical application program has a top level or main message loop that allows the application program to read input messages from a main message queue and dispatch the input messages to the appropriate components in an orderly manner. If a component interrupts the main message loop of the application and initiates its own message loop, a parallel execution stack may be created. This may cause the component to return processing to the main message loop in a manner that causes the application program to become unstable and crash unexpectedly. This, of course, is most undesirable. Other major problems would be caused by this type of private message loop because it probably would not include the proper logic for handling keyboard accelerators. It would also inhibit the allocation of idle time to other components. Therefore, a post-release component, whose operation cannot be known in advance, should not be permitted to operate its own message loop. Instead, a post-release component should be configured to rely on the main message loop processing of the underlying application program.
This restriction complicates the allocation of idle time, which allows an application program to perform idle time tasks, such as background printing, computing, or data transferring. In response to an idle condition, such as the main message queue being empty, the application program allocates idle time to components that have idle time tasks to perform. Prior component integration systems are not able to allocate idle time to post-release component that have idle time tasks to perform. Moreover, idle time may occur when the application program is waiting for a return from a message dispatched to a component. If idle time occurs when a post-release component is executing a function, prior component integration systems are not able to allocate this idle time to other components.
In addition, the application program may be configured to detect specific key combinations that map to predefined command. These specific key combinations, such as Ctrl-S for a save command, are referred to as accelerator messages. When the application program notices an accelerator message, the application program executes a predefined function call, such as a save function call, rather than dispatching the message to a component. It would be advantageous for the application program to be able detect accelerator messages directed to a post-release component. But because post-release components are typically not permitted to run their own message loops, there is no mechanism in place for routing accelerator and other messages to the post-release components. Those skilled in the art will understand that the previous statement refers to general components that are not in an OLE/COM in-place relationship. OLE in-place objects do have a mechanism for routing accelerator and other messages to post-release in-place components. However, prior component integration systems do not generalize this concept to components that are not OLE in-place objects.
Therefore, there is a need for a component integration system that may selectively route accelerator and other messages to a component for translation prior to translation by the host application program. There is a further need for a component integration system that allocates idle time to various components running within a single thread or process, disables components at appropriate times, and notifies components of application program state changes. There is a further need to provide this component integration system with a standard interface so that components supplied by various groups, including post-release components, may be properly integrated into the application program.